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Smart card with business partner scheme, or travel application 

TL^f r/ro^rnH^'^T^" common application, e.g. a cardholder identification application 404. 406. and 
at least one second apphca .on concerned with a travel related and/or business partnering scheme application 

date (Figure 6) an airline n.ght and ticket application 410, a hotel reservation application 412 or a hire caV 
application 4 4 having details of the card holder's preferred car (Figure 8). Preferably aTof the L^^^^^ 
partners invoked ,n the partnering scheme have access to the common application, contain ng th^^^^^ 

also be stored on the smart card, e.g. msurance. biometrics data, driving licence, passport and social securitv 

^^^n^rT^^^^^^ '""'^ '^^''^^ ' ^^^'^^'•'^9 organisation ser^e'a^r^^^^^^^^^ 

network ( 19, Figure 10), for use with the smart card are also disclosed. 
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Smart Card with Business Partner Scheme or Travel Applications 

The present invention relates generally to the use of integrated circuit cards, or 
"smartcards", for commercial transactions and, more particularly, to methods and 
apparatus for conveniently storing, retrieving, and updating data related to a 
cardholder's travel information in the context of a distributed transaction system. 

Despite advances in information technology and process streamlining with 
respect to travel arrangdnents, the modem traveller is often subjected to unnecessary 
delays, petty inconveniences, and oppressive paperw^k. These travel burdens are most 
evident in the airiine, hotel, and rental car industries, where arranging and paying for 
services and accommodations can involve significant time delays due to 
miscommmucation, poor record-keeping, and a host of other administrative 
inefiiciencies. 

Smartcard technology, as described below, has had limited success in addressing 
some of these problems. The term "smartcard** refers generally to wallet-sized or 
smaller cards incorporating a microprocessor or microcontroller to store and manage 
data within the card. More complex than magnetic-stripe and stored-value cards, 
smartcards are characterized by sophisticated memory management and security 
features. A typical smartcard includes a microcontroller embedded within the card 
plastic which is elecUically connected to an array of external contacts provided on the 
card exterior. A smartcard microcontroller generally includes an electrically-erasable 
and programmable read only memory (EEPROM) for storing user data, random access 
memory (RAM) for scratch storage, and read only memory (ROM) for storing the card 
operating system. Relatively simple microcontrollers are adequate to control these 
junctions. Thus, it is not unusual for smartcards to utilize 8-bit, 5 MHZ 
microcontrollers with about 8K of EEPROM memory (for example, the Motorola 680S 
or Intel 8051 microcontrollers). 

A niunber of standards have been developed to address general aspects of 
integrated circuit cards, e.g. ISO 7816-1, Part 1: Physical characteristics (1987); ISO 



78Jf.2 Pan 2: Dimensions and location of the comocts (1988); ISO 7816-3. Pan 3: 
Elec.ronicsisru.Uand,ransn,issionpro.OCobi\m^^^^^ 1992. An,d.2 1994);/SO 
78J6^. Port 4: Inier-indusiry commands for interchange (1995); ISO 7816-5. Part 5: 
/^umbering system and registration procedure for application identifiers (1994. Amd. 1 

5 ^^,)S)iSO/lECDlS7816-6.1nier.indusirydoiaelements{\995yjSO/lECWD78l6-7. 
Par, 7: Enhanced inter-industry commands (1995); and ISO/lEC WD 7816-8. Par, 8: 
,„,er.indvstry security architeavre (1995). TT^csc standards are hereby incorporated by 
reference. Funhermorc, genera) informsiion regarding magnetic stripe cards and chip 
cards can be found in a number of standard texts, e.g.. Zoreda & Oton. SMART CaRDS 

,0 (1994). and RankI & EfTmg. Smart Card Handbook (1997), the contents of which are 

hereby incorporated by reference. 

Various attempts have been made toallcviate travel-related inconveniences through 

the use of smartcard technology. In 1995. for example, the U.S. airline industry led an 
effort to reduce ticket distribution costs by developing standards for "ticketless travel." 
,5 soonthereafier.ajointconferenceof lATAandATAadoptedasetofspecifications 

MtASpecificatians for Airline Industry Integrated Circuit Cards (hereinafter, "lATA 
standard"). Similarly. In the Held of financial payment systems, a standard has been 
developed entitled EMV Version 2.0. Integrated Circuit Card Specifications for Payment 
Systems. Ports 1-3 (1995). Both of these specifications are hereby incorporated by 
20 reference. 

Nol^viths.anding widespread promulgation of these standards, smartcard efforts 
,end .0 remain fragmented, and the resultant benefit to consumers - panicularly 
consumers who travel has been quite minimal. One recent study estimates that 
approximately nine million smartcards w«e issued in the transportation and travel 
in 1 996. yet. for the most part, these cards remain incompatible; that is. due to 
differing file stn^ctures and/or communication F«ocols employed, card data typically 
can not easily be shared across applications or between industry participants. 

Systems and methods are therefore needed in order to overcome these and other 
shortcomings in the ;ffior art. 
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The present inveniion pro^odcs mcihods and apparatus for a smartcard system 
which securely and conveniently iniegraies important travel-related applications, thereby 
overcoming the limitations of the prior an. In accordance with one aspect of the present 
invention, a smartcard system comprises a cardholder identification application and 
various additional applications useful in particular travel contexts; for example, airline, 
hotel, rental car^ and payment-related applications. In accordance with another aspect of 
the present invention, a smancard system further comprises space and security features 
within specific applications which provide partnering organizations the ability to 
construct custom and secure file structures. 

The present invention will hereinafter be described in conjunction with the 
appended drawing figures, wherein like numerals denote like elements, and: 
Figure 1 illustrates an exemplary smancard apparatus; 

Figure 2 is a schematic diagram of an exemplary smancard integrated circuit, 
showing various functional blocks; 

Figure 3 is an cxamplary diagram of files and directories arranged in a typical tree 
structure; 

Figure 4 sets fonh an exemplary database structure in accordance with a preferred 
embodiment of the present invention; 

Figures sets fonh a prefened cardholder ID data structure in accordance with the 
present invention; 

Figure 6 sets fonh a prefened payment system data structure in accordance with . 
the present invention; 

Figure 7 sets forth a prefened airline data structure in accordance with the present 
invention; 

Figure 8 sets forth a preferred rental car data structure in accordaiice v^th the 
jmsent invention; 

Figure 9 sets forth a preferred hotej system data structure in accordance with the 
present invention; and 



Figure 1() illiistraies an exemplary disiribmed transaction system useful in 
practicing the present invention. 
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Referring now lo Figures I and 2, an exemplary smartcard sysiem suitable for 
practicing the present invention will now be described. A smartcard 100 generally 
comprises a card body 102 having a communication region 104 for providing contact or 
non-contact communication bcnvccn an external device {e.g., a card reader) and an 
inteerated circuit 1 JO encapsulated within card body 102. Communication region 104 
preferably comprises six conductive pads 106 whose placement and size conform to 
1S07816-2. More particularly, a communication region 104 in conformance with ISO- 
78 1 6-2 preferably comprises VCC contact 1 06(a) (power supply), RST contact 1 06(b) 
- (reset), CLK contact 1 06(c) (extcmal clock), CND Contact 1 06(d).(ground), VPP contaa 
106(e) (programming voltage), and 1/0 contact 106(0 (data I'nO- 
j5 VCC 106(a) suitably provides power to JC 11 ©(typically 5.0V+/- 10%).CLK 

106(c) is suitably used to provide an extcmal clock source which acts as a data 
ttansmission reference. RST 106(b) is suitably used to transmit a reset signal to IC 1 10 
during the booting sequence. VPP contact 106(e) may be used for programming of 
EEPROM 212 in JC 1 10. As is known in the art, however, this contact is generally not 
20 used since modem ICs typically incorporate a charge pump suitable for EEPROM 
programming which takes its power from the supply voltage (VCC 106(a)). J/0 106(0 
suitably provides a line for serial data communication with an external device, and GND 
106(d) is suitably used to provide a ground reference. Encapsulated integrated circuit 
no is configured lo communicate electrically with contacts 106 via any number of 
Jtno^wi paclcaging techniques, including, for example, thennosonically-bonded gold 
wires, tape automated bonding (TAB), and the like. 

While an exemplary smartcard is discussed above in the context of a plurality of 
external contacts, it vwll be appreciated that contactless cards nMqr also be titilizcd to 
practice this invention. That is, non-contact communication methods may be employed 
using such techniques as capaduve coupling, inductive cotipling. and the like. As is 
known in the ait, capadtive coupling involves in«»iporating capactiive plates into the 
card body such that data tnmsfer with a card reader is provided through synwnetric paiis 
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of coupled surfaces, wherein cnpaciiancc values are typically 10-50 picofarads, and the 
working range is typically less ihan one millimeter. Inductive coupling employs coupling 
elements, or conduciivc loops, disposed in a weakly-coupled transformer configuration 
employinc phase, frequency, or nmpfiiude modulation. In this regard, it will be 
appreciated thai the location of conimunicaiion region 104 disposed on or within card 
too may vary depending on card confmuraiion. For additional information regarding 
non-contact techniques, see. for example, contactlcss card standards ISO/IEC 10536 and 
ISO/IEC ) 4443, which are hereby incorporated by reference. 

Smaricard body 102 is preferably manufactured from a sufficiently rigid material 
which is resistant to various environmental faciors, e.g.. physical deterioration, thermal 
extremes, and ESD (elecirosiaiic discharge). Materials suitable in the context of the 
present invention include, for example, PVC (polyvinyl chloride), ABS (acrylonitrile- 
butadicne-siyrol), PET (polyethylene tcrephihalate), or the like. In a preferred 
embodiment, chip card 100 confomis to the mechanical requirements set forth in ISO 
7810, 7813, and 7816. Body 102 nwy comprise a variety of shapes, for example, the 
rectangular lD-1, lD-00, or ID-000 dimensions sei forth in lSO-7810. In a preferred 
embodiment, body J 02 is roughly the size and shape of a common credit card and 
substantially conforms to the lD-1 specification. 

Referring now to Figure 2, IC 110 preferably comprises regions for Random 
Access Memory (RAM) 216, Read-Only Memory (ROM) 214, Central Processing Unit 
(CPU) 202, data bus 210, Inpui/Ouipui (1/0) 208 and Electrically-Erasable and 
Programmable Read Only Memory (EEPROM) 212. 

RAM 216 comprises volatile memory which is used by the card primarily for 
scratch memory, e.g., to store intermediate calculation results and data encryption 
processes. RAM 2)6 preferably comprises at least 256 bytes. 

EEPROM 212 provides a non-volatile memory region i^ich is erasable and 
rewritable electrically, and which is used to store* inter alia^ user data, system data and 
application files. In the context of the present invention, EEPROM 2)2 is suitably used 
to store a plurality of files related to cardholder travel infomoation (discussed in gieater 
detail below in conjunaion with Figure 3). EEPROM 2 12 preferably comprises at least 
8K byics. 
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In n preferred cmbodimcnu CPU 202 implements the insmictionsci stored in ROM 
202. har^dles memo management (i.e.. RAM 216 and EEPROM 212). and coordinates 
inpui/outpui aciiviiies (i.e.. 1/0 208). 

ROM 214 preferably contains, or is "masked" vnth. the sntart card operating 
system (SCOS). TTia. is. the SCOS is preferably implemented as hard-wired logic in 
ROM 214 using standard mask design and semiconductor processing methods well 
known in the art (e.g.. photoli.hogn.phy, diflusion. oxidation, ion implantation, etc.). 
Accordingly. ROM 2 14 cannot generally be altered after fabrication. The pun)Ose of such 
an implementation is .0 take advantage of the fas, access times provided by masked 
ROMs. ROM 2 14 suitably comprises about 4K-20K bytes of memory, preferably at leas, 
,6K bytes. In this regard, i. will be appreciated that ahemate memory devices may be 
„cd/m place of ROM 214. Indeed, as semiconductor technology progresses, it may be 
advanogeous ,o employ morecompact forms of memonr. for example. flash-EEPROMs. 

The SCOS controls information flow .o and from the card, and more particularly 
facilitates storage and retrieval of data stored within EEPROM 212. As wi.h any 
operating system, ,be SCOS operates according to a well-def.ned command set. In th.s 
regard a variety of known smart card operating systems are suitable for the purpose of 
Ais invention, for example. IBM's Multi-Function Card (MFC) Operating System 3.5 1 . 
,he specification of which is hereby incorporated by reference. While the IBM MFC 
operatin- system employs the standard tree structure of files and directories substantially 
in accordance with 1S07816-4 (as detailed below), it will be appreciated by those skilled 
in ,he art that other operating system models would be equally suitable for 
implementation of the present invention. Moreover, it may be advantageous to allow 
eenainaspects of operating system functionality to exist outside the card, i.e.. m the fom, 
of blocks of execuuble code which can be downloaded and executed by the smartcard 
durmg a transaction (for example, Java applets. ActiveX objects, and the like). 

Given the general characteristics of smartcard 100 as ot,tlined above, it will be 
apparent that a wide range of miaocontrollers and contact-based smartcard prodtKts 
k«>wn in the art may be used to implemem variotts embodiments of the present 
invention. Suitable smartcards ir.cl«de. for example, the model ST16SF48 card. 
r^^sct^ by SGS-Thomson Microelectronics, which incorporates a Motorola 6805 
microcontroller with I6K ROM. 8K EEPROM. and 384 bytes of RAM. I. ^v.^ be 



npprcciaicd, however, ihal particular erobodimcnis of the present invention might require 
more advanced microconuollcrs wilh greater EEPROM capacity (i.e., in the range of 
atK)ui ] 2- 1 6K). Such systems are well known in the art. 

Having thus described an exemplary smartcard J 00 and IC 1 1 0» an overview of n 
smartcard file siruaiirc in accordance with the present invention will now be described. 
Referring now to Figure 4, file structure 400 is preferably used to store information 
related to card-holder preferences and various data useftil for securing and paying for air 
iravel, rental cars, hotel reservations and the like. More particularly, file suuclure 400 
preferably comprises cardholder ID application 406, payment system application 408, 
airline applicaiion 410, hotel sysiem application 412, rental car application 4)4, and 
cardholder vcrificaiion data 404, It wilj be appreciated by those skilled in the art that the 
icrm "applicaiion" in ihis conicxi refers to sclf-coniaincd regions of data all direcicd ai 
a particular funciion (e.g., airline, hotel, etc.) rather than a block of executable software 
code, although ihc use of executable modules as part of any particular application falls 
within the scope of the present invention. 

Cardholder verification data 404 preferably houses data useful in verifying 
cardholder identity during a transaction. In a preferred embodiment, cardholder 
verification data 404 comprises two' eight-byte cardholder verification numbers (i.e., PIN 
numbers) referred lo as CHV J and CHV2. 

Cardholder ID application 406 suitably comprises various files related to personal 
information of the cardholder (e.g., name, addresses, payment cards, driver's license, 
personal preferences and the like). Cardholder ID application 406 is described in greater 
detail below in conjimction with Figure 5. 

Payment system application 408 suitably comprises information useful in effecting 
commercial transactions, e.g., account number and expiration date information 
traditionally stored on a magnetic-stripe credit card. Alternatively, Payment system 
application 408 comprises a full EMV-compliant application suitable for a wide range 
of financial transactions. Pajoneht system application 408 is described further below in 
conjunction with Figu re 6. 

Airline application 4 1 0 suitably comprises data helpful in streamJirung commercial 
airline travel; for example^ relevant personal preferences, electronic tickets, and frequent 
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nier informauon. Airline application 410 is discussed in gna.cr dcail below in 

conjunction with Figure 7. 

Hotel application 412 suitably comprises information useful for securing and 
paying for hotel reservations, including an array of information and preferences 
5 associated with a lis. of prefened hotels as xvell space for electronic keys. Hotel 
application 4 1 2 is discussed in greater detail below in conjunction with Figure 9. 

Rental car application 414 suitably comprises data useful in expediting the process 
of car rental and return, including, for example, car preference and frequent rental 
infomiation. Rental car application 4 14 is desaibed in further detail below in conjunction 

10 with Figure 8. 

In each of ibc above mentioned applications, sophisticated access and encryption 
schemes are preferably utilized in order to allow multiple parties to make use of certain 
file structures while preventing unauthorized eniiy into others. More specifically, 
partnering organizations (e.g.. hotel chains, airlines, and rental car agencies) may create 
Aeir own tailor-made file stn.ctorcs (i.e., "panner file structures") within card 100. 
Details of the various security measures employed are.described in further detail below 
in conjunciion with Tabic 40. 

Referring now to Figure 10, smancard 100 is suitably used in the context of a 
distributed transaction system. Briefly, cardholder's may employ smancard 100 at 
various access points 15 which arc connected via network 19 to an issuer 10 and at least 
one partnering organization 12. Issuer 10 suitably comprises various hardware and 
software components suitable for client host communications as well as a database 
. system l.I. In this context, the tem, issuer- refers to the on^anization that actually issues 
,he smartcard and retains some high-level access to certain areas of file stnicture 400 

25 (detailed below). 

Partnering organizations 1 2(aX 1 2(b). and so on. comprise the various hotel chains, 
rental-car agencies, airlines, and the like, who have access to appropriate data regions 
within smartcard 100. Each partnering organization 12 suitably comprises a database 13 
and approFiate hardware and soft>vare components necessary for compleung a 

30 " tninsaction over network 19. Netwcric 19 may comprise one or more comniunication 
modes, e*. the public switched telephone network (PS1>0. «hc Internet, digital and 
analog wireless networks, and the like. 
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Edcli access pi)ini IS suitnbly comprises an appropriaie card reader Tor interfacing 
wiih smancard 100 as well as hard^vare and software suiiable for imerfacing with a 
cardholder and performing a iransnciion over network 19. Access poinis 15 are preferably 
located in areas providing convenient access for traveling cardholder's or cardholder's 
preparing travel arrangements. Siurh access poinis 15 may be located, for example, in 
airline tickeiing and gale areas* rental car facilities, hotel lobbies, travel agencies, and 
stand-alone kiosks in mails. In addition, businesses might see fit to host an access point 
15 to streamline their employees' business travel. Furthermore, an individual cardholder 
might configtire his or her personal computer to act as an access point using appropriate 
software and peripheral hardware. 

In a preferred embodiment of the present invention, data files and directories are 
stored in n "tree" stnictitrc as illiistmicd in Figure 3. That is. the smancard File siniciure 
resembles the well known MS-DOS (Microsoft Disk Operating System) file structure 
wherein files arc logically organized within a hierarchy of directories. Specifically, three, 
types of files are defined in ISO 7816-4: dedicated files (DF): elcmemary files (EF), and 
a master file (MF). The master file is analogous to the MS-DOS "root" directory, and 
contains all other files and directories. Dedicated files are actually directories or "folders" 
for holding other DFs or EFs. Tlius. MF 302 may contain an arbitrary number of DFs 
306, and these DFs (e.g., DF 306(a)) may or may not contain other DFs (e.g., DF 308). 
Elementary files arc used to store user data, and may exist within a dedicated file (c.g., 
EF 3 1 0 within DF 306(a)), or within the master file (e.g., EF 304 ^yilhin MF 302). Higher 
level DFs (i.e., DFs which hoiise particular applications) are often referred to as 
application dedicated files (ADFs). 

The MF and each of the DFs and EFs are assigned a unique two-byte file identifier 
(FID). By convention, the MF is traditionally assigned an FID of 3F00' hex. Selection 
of an EF or DF by ihe operating system may then be peHbrmcd by tracing its entire path 
starting at the MF. Thus, if the MF contains a DF with a FID 'A 100*, and this DF in turn 
contains an EF with a FID 'AlOr, then this EF could be referenced absolutely by 
successive selcciion of FIDs 3FO0, AIOO, and AlOl. It will be appreciated that the FID 
is essentially a file name used by the operating system to select directories and files; it 
is not intended to indicate a physical address within EEPROM 212. As will be 
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uppreciaicd by .hose skilled in .be art. low-level EEPROM addressing is preferably 
handled by ihe SCOS in conjimciion with CPU 202. 

Each nie preferably has an as-wiaied file header coniaining various indicia of the 
particular EF, DF. or MF. More particularly, ihe file header associated with a particular 
file preferably includes .he file identifier (FID), file size, access conditions, and file 
s,ruc.ure. In this regard, smartcard lOO suitably employs one of four file structures: 
transparent, linear fixed, linear variable, or cyclic. For the sake completeness, the nature 
of these file structures v^oll be brieJly reviewed. 

A tmnspaxen. file structure consists of a string of bytes accessed by.spccifying an 
offse. and bvte count. For exnmple, with reference .0 T»ble I below/givcn a «-byte 
string of data, bytes 7 through 10 ^vould be accessed using an offset of six and a length 
of four. 
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Tabic J : Transparent file structure 

A linear fixed file structure comprises a plurality of records of equal length (eg.. 
3 list of phone numbers), wherein access to ah individual record is achieved through 
reference .0 a record number. In addition, it is possible to refer to the -next' or 'prevtous' 
record relative to the 'currenf record (i.e. the most recently accessed record). In contrast. 
3 rmear variable file stnacture comprises records of arbitrary but taown length, and ,s 
Oterefore typically more compact than linear fixed data stnicnues, 

A cyclic file structure is a type of linear fixed file wherein a pointer is used to potnt 
,0 the las. data set written to. After the last data record is wrinen to. the pointer returns 
,0 the firs, record. Tlta. is. a cyclic file comprises a series of records anranged m a 'nng . 

A dau structure particularly important with regard to storing records as well as 
secure messaging in smartcard applications is the BER tag-length^value or -TLV" 
s,nK.u«i»accordancewithISO/lEC8825.herebyincorpora.edbyrefe,«K^^ InaTLV 
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objccu infomiaiion regarding ihc iype and length of the information is included along 
with the actual data. Thus, a TLV object comprises a tag which identifies the type of data 
(as called oui by the appropriaic specification), a length field which indicates the length 
in byics of the data to follow, and a value field, which comprises the primary data. For 
example, the TLV object illustrated in Table 2 below encodes the text *'phocnix*\ which 
has a length of 7 bytes, and conesponds to a the "city" lag of '8C' hex (a hypothetical tag 
designation). 
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Value 
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Table 2: Exemplary primitive TLV object 



It will be appreciated that the meaning of the various tag values must be known to 
the system o priori. That is, in order for the tag field to be useful, the smartcard and any 
cxicrnal systems communicating with the smartcard must confomi to the same tag 

1 5 specification. In this regard, ISO/lEC 78 16-6 defines a scries of tags useful in the context 
of the present invention, as does the IBM MFC 3.2 specification. ISO/IEC 8825 sets 
forth the basic encoding rules for a TLV system and defines a "template'* data object 
which can be used as a container for multiple TLV objects. That is, it is often 
advantageous to encapsulate primitive TLV objects wiihin a larger template which is 

20 itself a TLV object. 

Referring now to Figure 4, a preferred smartcard data structure in accordance with 
the present invention will now be described in detail. Data structure 400 preferably 
comprises a MF 402 and five DFs: Cardholder ID application 406, Payment system 
application 408, Airline application 410, Hotel application 412, and Rental car 

25 application 414. 

In the detailed description to follow, various acronyms and abbreviations will be 
used to refer lo particular data types, formau, and the like. A key to these acronyms and 
abbreviations is presented in Table 3 below. 

AN Alphanumeric 



II 



N 


Numeric 


B 


Boolean 


C 


Convention 


M 


Matrix 


D 


Data 


AR 


Bits array 


BIN 


Binary 


RJ 


Right-justified 


U 


Lxft-justified 


BCD 


Binary coded decimal 




TABLE 3: Key to acronyms 



,„ the discussion Ihat foIIo>vs. .he various features of a preferred data structure 
arc in some cases described using particular file structure types (i.e., tra,tsparer,t, 
fixed etc.). Those skilled in the art will realize, however, that any of the common 
sn,art«rd file structure types are typically sui.able for implementing any particular 
da« structure. For example, when a f.le structure is described as including "a plurality 
of records " it ^vill be understood that such a structure may be designed, for example, 
using a lis. of records assembled in a linear fixed file wherein each record is itself a 
.ransparen. file (and offset values correspond to the various fields). Alternatively, 
such a sTucure may be designed using TLV strings assembled in a linear fixed file or 
within a larger template TLV. This is the case notwithstanding the fact that particular 
.ag values - which are for the most part arbitrary - ore no. explicitly listed in the 
tables that follow. 

Cardholder ID Application 

RefcTing now to Figure 5. Cardholder ID application 406 is used to store various 
infom^ation related to the cardholder. Portions of.this information are freely available to 
UK partnering organizations, thereby preventing the storage of redundant informatton. 

More particularly, cardholder ID application 406 preferably comprises directory 
EP 532 bolder JD DF 502 and miscellaneous DF 530. HolderJD DF 502 preferably 
compri^ ID EF 504. home EF 506. business EF 508. preferences EF 5M. passpon EF 
5,6 authentication EF520.biometricEF 522. and driver EF518.MiscellaneousEF530 

p^feniblycomprisespayment card EF 510. sequence EF 5l2.issu«K^ 



12 



programs EF 52S, and card number EF 526, These files and iheir respective functions arc 
discussed in detail below. 

Dircctoiy EF 532 provides a iisi ofapplicaiion idemificrs and Inbels for the various 
high-level DF's existing under cardholder ID application 406. Thai is. this file serves the 
function of a higWcvcI diiecior>' listing which specifies ihc locotion (i.e., FID) and 
application label for each DF - in this case, holdcr^lD DF 502 and miscellaneous DF 
530. In a panicularly preferred embodimcni, dircctoty EF 532 is siruciured in accordance 
with EM V 3.0 as shown in Table 4 below. Preferably, each major application (e.g., hotel, 
airline, etc.) has an associated director}' file ^viih a subsianiially same file structure. 



Kccortt UcscripitoM 


Hxirrnal rornial 


Internal rorimic(bylcs) 




Size 


Type 


Size 


Type 


Applicarion ID for hoidcr_ID DF 


16 


AN 


16 


ASCII 


Application label 


16 


AN 


16 


ASCII 


Application ID for miscellaneous DF - 


16 


AN 


16 


ASCII 


Applicaiton label 


16 


AN 


16 


ASCII 



Tabic 4: Exemplar)' cardholder ID directory EF 



ID EF 504 preferably includes personal infonmation related to the cardholder, e.g., 
name, date of binh, emergency coniacu general preferences, and the like. In a particularly 
preferred embodiment, member EF 504 comprises the fields set forth in Tabic 5 below. 
Italicized field names indicate a Nubcate^ory within a particular field. 



Record description 


Exierpsl form<t 


Internal form8t(byie$) 




Size 


Type 


Size 


Type 


LastName 


30 


AN 


30 


ASCIJ 


First Name 


20 


AN 


20 


ASCI] 


Middle Name 


S 


AN 


8 


ASCII 


HonoraiyTdle 


S 


AN 


8 . 


ASCII 


Name SofTw 


4 


AN 


4 


ASCII 


Date of Binh 


8 


P 


4 


BCD 



Cnr iai Secufiiv Numbcr 


10 


AN 


10 


ASCII 


tinCr§CliCjr v^wiiuiwi 












70 


Al^ 


70 


ASCII 


First Nomr 


10 


AN 


to 


AXII 


Motion 


f 


C 


/ 


BIN 




70 




10 


BCD 


Gender 


1 


AN 


\ 


ASCII 


Special Perjorwl Rcquircmcnis 


12 


AN 


12 


M 


1 anouaee Preference (ISO 639) 


2 


C 


2 


ASCII 





10 



Tabic 5: Exemplary ID EF data sirociurc 
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20 



In .he above tabic, and the tables lo follov,. both internal and external data 
formats are listed. As the conservation of EEPROM space is of paramount 
i„,por.a„ce. the "internar fonna. of data (i.e.. within EEPROM 212) may be 
different from the "extemar forma, of the data (i.e. as read by the card reader at 
an access point 15). Thus, for example, a date fteld might consist of a fot«-byte 
BCD record within the card, b«. upon reading and processing by the terminal, this 
data might be converted to an eieh.-by.e decimal value for more convenient 
processing. 

Home EF 506 preferably includes data related to one or more.of the 
cardholder's home addresses. In a particularly preferred embodiment, home EF 506 
comprising the fields set forth in Table 6 below, "nte personal .ra^^l charge accotm. 
pointer is preferably used to designate a preferred paymem card, and consists of. 
number corresponding to one of the payment card records within payment card EF 
510 (detailed below). 



25 



Record description 


External formst 


iDtcrnil for 


inst(bytes) 




Size 


Type 


Size 


Type 


HomeAddiessI 


40 


AN 


40 


ASCII 


Home Address 2 


40 


AN 


40 


ASCII 


Hftmc Address City 


25 


AN 


25 


ASCII 
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Home Address SiMc 


.5 


AN 


5 


ASCII 


Home Couniry(IS03l66) 


2 


AN 


2 


ASCII 


Home Address Zip Code 


10 


AN 




ASCII 


Home Address Telephone 


20 


N 


10 


BCD 


Home Address FAX 


20 


N 


10 


BCD 


Home E-mail 9ddrts& 


40 . 


AN 


40 


ASCII 


Personal travel charge accouni number 
pointer 


2 


N 


1 


BCD 



Table 6: Excmplaiy home EF file siniciurc 



Business EF 508 preferably includes various data related lo ihe cardholder's 
business (i.e., addresses, phone numbers, and the like). In a particularly preferred 
cmboidimenl, business EF 50S comprising the fields set forth in Table 7 below. In 
this regard, the credit card pointer field is preferably used to point lo a payment card 
record within payment card EF 510 (detailed below). The cost center, dept., 
division^ and employee ID fields are employer-specific, and may or may not apply 
in a given case. 



Record descriplion 


External formal 


Internal rormst(byics) 




Size 


Type 


Size 


Type 


Business Address 1 


40 


AN 


40 


ACSII 


Business Address 2 


40 


AN 


40 


ASCII 


Business Address City 


25 


AN 


25 


ASCII 


Business Address State 


5 


AN 


5 


ASCII 


Business Counny (ISO 3 1 66) 


2 


AN 


2 


ASCII 


Business Address Zip Code 


10 


AN 


10 


Asai 


Business Telephone No. 


20 


N 


10 


BCD 


Business Address Fax 


20 


N 


10 


BCD 


Business E-mail Address 


40 


AN 


40 


ASCII 


Professional TiUc 


10 


AN 


10 


ASCII 


Einplo)reelD 


10 


AN 


10 


ASCII 



15 



10 



15 



Division 


20 


AN 


20 


ASCII 


Dcp» 


20 


AN 


20 


ASCII 


Cosi Ccnicr 


12 


AN 


12 


ASCII 


Professional iravcl account number 
pointer 


2 


N 


2 


BCD 


Professional license data 


20 


AN 


20 


ASCII 


Credit Card pointer 


2 


N 


1 


BCD 


Company Name 


20 


AN 


20 


ASCII 



Tabic 7: Exemplary business EF file siniciure 

Preferences EF 514 preferably comprises daia related to the cardholder's 
default personal preferences. In a particularly preferred embodiment, preferences 
EF 514 includes a field comprising an array of preferences as sel forth in Table 8 
below. Preference values are preferably chosen from a list of preference tags as set 
forth in Table 39. 



Record description 


External to 


rmat 


Internsl for 


m8i(byic5) 




Size 


Type 


Size 


Type 


Preferences Array 


20 


C 


20 


C 



Tabic 8: Examplary preferences EF file structure 
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Passport EF 5 1 6 is preferably used to store cardholder passpiwt informaUon. 
In a particularly preferred embodiment, passport EF 516 comprises the fields set 
forth in Table 9 belovr. 



Record description 


External fo 


rm«i 


-Internal for 


ip»t(bytcs) • 




Size 


Type 


Size 


Type 


Pi;Sspon Number 


20 


AN 


20 


Asai 


Passpon Country- ISO 3 166 


2 


AN 


2 


ASCII 


Issuatice Me 


S 


D 


4 


BCD 



25 



16 



Cay of Issuance 


30 


AN 


70 


AN 


Expiration Dale 


8 


D 


4 


BCD 



Table 9: Examplary passpon EF file siruciure 



Driver EF 516 preferably comprises cardholder driver license data. In a 
panicularly preferred embodimcnl, driver EF 518 comprising ihc fields scl forth in 
Table 10 Mow. 



Record description 


Exicrnul formsl 


Inlcrnal fi>rmai(b3'ies) 




Size 


Type 


Size 


Type 


Driver's License No. 


20 


3 


20 


ASCII 


Driver's License Issuing Staic/Couniry 


2 


a 


2 


BCD 


License Expiration Dale 


S 


D 


4 


ASCII 


License Type 


2 


C 


4 


BCD 



Table JO: Exemplary driver EF file structure 



Biometric EF 522 is used lo store biometric data (preferably encoded) such 
as fingerprint data, retina scan data, or any other sufficiently unique indicia the 
cardholder's physical or behavioral characteristics. In a particularly preferred 
embodiment, biometric EF 522 comprises a single data string as set fpnh in 
Table 1 J below. 



Record description 


Eyiernat format 


Internal format (bytes) 




Size 


Type 


Size 


Type 


Biometrics template 


100 


AN 


100 


BIN 



Table J J: Exemplary biometric EF file structure 



Authentication EF 520 preferably comprises information for static 
authentication of the cardholder ID 406 application. This data is iinique for each 
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card, nnd is sofT.cicntly comple.N such thai counterfeit values cannot feasibly be 
created. This prevents creation of "new" counterfeit cards (i.e.. cards with new 
authentication data), bu. does not prevent creation of muhiple copies ofthc 
current card. 

,„ n particularly preferred embodiment, authentication EF 520 includes 
public key certificate fields as shown in Table 12 below, wherein the external 
format is identical to .he internal format. Preferably, the issuer RSA key is 640 
bits long, and the CA key is 768 bits long. 



10 



15 



20 



Record dcscripiion 


Internal for 


mat(byics) 




Size 


Type 


Siiincd Sialic Applicaiion Data 


80 


B 


Static Daia Auihcmicaiion Tag List 


16 


B 


Issuer Public Key CeniHcaic 


96 


B 


Issuer Public Key Exponent 


1 


B 


Issuer Public Key Remainder 


20 


B 



Tabic 12: Exemplary authentication EF 

Turning now ,o files under miscellaneous DF 530. preferred programs EF 
528 preferably comprisesdau related to the cardholder's preferences as to airline 
companies, hotels. ami rental car agencies. Specifically, this EF. in a particu.aHy 
prefened embodiment, comprises a plurality of records (e.g., three) indicating 
prefored companies for each type of travel partner as shown in Table 13. The 
.ctual datt values confom. to an arbJuary convention; that is. each airline, hotel, 
and rental car agency is assigned an arbitrary thiee-byte code. 
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Tabic J 3: Exemplary programs EF 



Payment card EF 5 10 is preferably used fo catalog information related lo the 
cardholder's various payment c^irds. i.e., debit cards. char*!e cards* and the like. In 
a particularly preferred embodiment, payment card EF comprises card numbers aiKS 
expiration dates for two cards as shown in Tabic 14. The "ISO** and "non-ISC 
desijinaiions refer lo 1S0-7S 13, which specifics a panicular payment card number 
format. Thus, in a prefcned embodiment, cither an ISO or non-ISO card number 
scheme may be used. Moreover, ii will be apprcciaicd ihoi this data set is sufTicienl 
only for **card not present" in^nsaciions^ for example, transactions taking place 
remotely where only the card number and expiration dale arc required to efTeci a 
transaction. Data stored within payment system application 40S (described below) 
must be used to effect a "card present** transaction. 



Record description 


ETfcrnal format 


Intcrnjtl formsl(bytes) 




Size 


Type 


Size 


Type 


Frrsi Payment Card P (ISO) 


19 


N 


10 


BCD 


First Payment Card Expiration Dale 


€ 


D 


4 


BCD 


Second Payment Card # (non-ISO) 


20 


AN 


20 


ASCII 


Second Payment Card Expiration Date 


S 


D 


A 


BCD 



Table 14: Exemplary payment card EF file structure 



Sequence EF 512 preferably includes information used to provide 
synchronization of the host and smancard databases. In a particularly preferred 
embodiment, sequence EF 512 comprises a plurality of records comprising the field 
set forth in Table 15 below. This number is analogous to a 'Version** number for 
the data stored in the application. 



Record dcKriptioii 


external format 


Internal forma t(bytcs) 




Size 


Type 


Size 


Type 



19 



Sequence Number 




AN 




ASCII 



Tabic 15: Exemplar}' sequence EF file structure 

Card number EF 526 is used lo record a unique number identifying the 
smartcard, and may also be used for key derivation (as described in further detail 
bclpw). Preferably, card number EF 526 comprises a eight-byte string as set 
forth in Tabic J 6 below. 



Record descripiion 


external fo 


rniai 


lDiern»l for 


ni»t(byies) 




Size 


Type 


Size 


Type 


Cnrd Nunibcr 


S 


HEX 


S 


HEX 



Tabic J6: Excmplaiy card number EF 



10 



15 



Issuance EF 511 is used to record various delails related to the manrjer in 
which the application (i.e.. cardholder ID DF 406) was created. This file includes 
information related to the identity of the organrzation that created the 
application, as vrell as information related to the application itself. In a 
particularly prcfened embodiment, isstiancc EF 51 1 comprises fields as set forth 
in Table 17 below. 
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Field 


Exicrnsl form»l 


Internal fo 


rmm (bytes) 




Si2« 


Type 


Size 


Type 


Country Authority 




ISO 3166 


2 




Aoihority 


10 


R)D-ISO 
7«I6-5 


5 


HEX 


Application vcrskw 


5 


XX.YY 


2 


BCD 


Application expiration dtie 


S 


YYYYMM 
DD 


4 


BCD 


Application effective date 


8 


YYYYMM 
DD 


4 


BCD 



20 



Persona lizerCodt 


I 


AN 


J 


Ascn 


Personalization Location 


I 


AN 


1 


ASCII 



Tabic 17: Excmplaiy issuance EF file siruciurc 
The personalizer code field shown in T^iblc )7 refers to the organization 
that actually "personalizes** the file. That is, before a smartcard may be issued to 
the cardholder, the database structure must be created within EEPROM 212 
(Figure 2), and the initial data values (i.e., default preferences, cardholder name, 
pin numbers, etc.) must be placed in the appropriate fields within the various 
EFs. It will be appreciated that, given the nature of the present invention, the 
smartcard "issuer** and "personalizer"* for any given application may not be the 
same. Therefore, it is advantageous to record various details of the 
personalization process within smancard 100 itself Similar issuance file 
structures may be provided for the other major applications. 

Payment System Application 

Referring now to Figure 6, payment system application 408 preferably 
comprises a directory EF 61 0, issuer DF 602, and a number of optional DFs 603(a)- 
(n) for use by partnering financial organizations. 

Directory EF 610 preferably includes a list of application identifiers and 
labels as described above in the context of cardholder ID application 406. 

Issuer DF 602 comprises pay I DF 604, which includes data that would 
traditionally be stored v^nthin tracks on a magnetic stripe card (i.e., debit cards, 
charge cards, and the like). In a prefcned exemplary embodiment, pay! DF 604 
comprises a plurality of records having commonly known magt>etic-stripe fields as 
specified in Tabk 18 below. 



Record descriplion 


Exurnai formst 


Internal rorrost(bytcs) 




Size 


Type 


Size 


Type 


Format Code (Track 1 } 


1 


AN 


1 


ASai 



2) 



5 



PAN (Track 2) - 


15 


N 


8 


BCDF 

right 
paddtno 


Expiraiion daic ( Track 1 or 2 ) 


A 


YYMM 


2 


BCD 


Effcciivc dale f Track 1 or 2 ) 


4 


YYMM 


2 


BCD 


Discrciionsry data ( Track 1 or 3 ) 


5 


N 


3 


BCDF 

righi 

paddino 


Name ( Track 1 ) 


26 


AN 


26 


ASCII. U 
blank 
■paddin« 



Tabic 18: Exemplao' Pay' EF file siniciurc 



Airline Application 

Referring now lo Figure 1, airline application 410 preferably comprises 
directory EF 730. common DF 702. and issuer DF 704. and additional airline 
10 applications 703(a). 703(b), and so on. 

Directory EF 730 preferably includes a list of application identifiers and 
labels as described above in the context of cardholder ID application 406. 

Common DF 702 generally includes data accessible to all participating 
airlines. v*ile issuer DF 704 generally includes data which can only be read or 
vwitten to by the smartcard issuer. Airline application 410 preferably further 
comprises at least one (preferably three) additional DF 703 for use by airline 
partnering organizations. That is, one airline partner may have access to and specify 
ihe structure of data stored vwthin DF 703(8) (as >vcll as common EF 702). vAiWc 
another airline might have similar access to DF 703(b). These panner DFs 
20 preferably conform to the relevant portions of the lATA spccificalion. 

Common DF 702 suiubly comprises common data ««ch v«Hild be of use io 
any of the various pannering airlines, i-e., passenger EF 706. frequent flier EF 708. 
lET EF 710, boarding EF 712, and biomelric EF 714. 
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Issuer DF 704, in conirasi, comprises informaiion readable by all, bin 
updaiable only by ihc card issuer, i.e., preferences EF 7)6, PIN EF 718, and 
issuance EF 720. 

Referring now lo informaiion siorcd within common EF 702, passenger EF 
706 preferably comprises various records related lo ihe passenger as spcciFied in 
Table 19 below. 



15 



Record description 


Cxicrnal format 


Iniemul formal (bytes) 




Size 


Type 


Size 


Type 












Passenger Name 


49 


AN 


49 


ASCII 


Gender 


1 


A 


1 


BIN 


Language Preference 


2 


AN 


2 


ASCII 


Unique ID 


24 


AN 


24 


ASCII 


A irline /D(3 htters code J 


. 3 


AN 


J 


Asai 


Type code ( 7 letiers ) 


2 


AN 


2 


ASCII 


Unique ID 


19 


AN 


J9 


ASCJJ 


Application version 


2 


N 


2 


BIN 



Tabic J 9: Exemplary passenger EF file sirucuirc 



In a particularly preferred embodiment, frcqucni flyer EF 708 comprises a 
plurality of frequent flier numbers (e.g., ten numbers) having the structure specified 
20 in Table 20 below. 



Record description 


External formal 


Internal format (bytes) 




Size 


Type 


Size 


Type 


Airline Customer ID 


22 


AN 


22 


ASCII 



Table 20: Exemplaiy frequent flyer EF file structure 
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lEfEF 71 Oprefcrabh' comprises a plurnlity of clccironic ticket records as set 
forth in Tabic 2 J below. The fomwi of these electronic tickets preferably conforms 
10 ihe IATA standard. 



Description of ibc rcconJs 


E^ctrrnal forniai 


internal for mm (b>ics) 




Size 


Type 


Size 


Type 


lETI 


14 


AN 


14 


BIN 


IET2 


M 


AN 


14 


BIN 


IET3 


14 


AN 


14 


BIN 


IET4 


14 


AN 


14 


BIN 


IET5 




AN 


14 


BIN 



Tabic 21: Exemplary lET fiJe structure 



Jn a particularly preferred embodiment, boarding EF 71 2 comprises boarding 
data to be used during check in as specified in Tabic 22. The formal of this data 
preferably conforms lo the JATA specification. 



Record description 


Eiitrnal format 


Internal format (bytes) 




Size 


Type 


Size 


Type 


Boarding data 


40 


AN 


40 


ASCII 



Tabic 22: Exemplary boarding EF file siructure 



Biomctric EF 714 is suitably used lo store biometric data associated with the 
cardholder, c.g., retina scan data, fingerprint data, or any other sufficicnlly unique 
indicia of the cardholder's physical or behavioral characteristics. In a particularly 
prcfencd embodiment, biomctric EF 714 comprises data as specified in Table 23 
below. 



Record dcscripitoD 


External format 


Internal format (bytes) 




Size 


Type 


Size 


Type 



24 



D romcirks dain 


100 


AN 


100 


BIN 



Tabic 23: Exemplary biomciric EF file structure 



Jssunnce EF 720 is suirnbly used lo hold daia related to the issuance of the 
various applicDiions. In a pnriicularly preferred cmbodimenl, issuance EF 720 
conipriscs a data siruciurc as specified in Tabic 24 below. 



Field 


Extcrnjil formst 


Inlernul formal (bytc$) 




Size 


Type 


Size 


Type 


Country A uihoriiy ( 2 letters ) 




ISO 3 166 


2 




Issuer A uihoriiy 


10 


RID -ISO 
7816-5 


5 


HEX 


Application venion 


5 


XX.YY 


2 


BCD 


Applicsiion expiration date 


S 


YYYYMM 
DD 


4 


BCD 


ApplicBtion effeciivc date . 


S 


YYYYMM 

DD 


4 


BCD 


Personalizcr Code 


1 


AN 


1 


ASCII 


PcrsonalizAtioii Location (cusiom code) 


1 


AN 


1 


ASCII 



Table 24: Exemplary issuance EF file structure 



PIN EF 71 8 is suitably used lo store PIN values corresponding to each of the 
participating airline partners. In a particularly preferred embodiment, PIN EF 71 8 
comprises a plurality of records having the structure specified in Table 25 below, 
vAerein each record is related to the corresponding eiitiy in frequent flyer EF 708 

(i.c^ record one in EF 718 corresponds to record one in EF 708, and so on.) 



Record description 


external formal 


Internal formal (bytes) 




Size 


Type 


Size 


Type 


PIN 


8 


AN 


8 


BIN 


Expiration date 


8 


D 


4 


BCD 



.25 



i 

Tnbic 25: Excmplaiy PIN EF file sinictiire 



Preferences EF 716, in a particularly preferred embodiment, compiises a 
preferences array as shown in Table 26 below. The preference values stored in this 
file correspond to those discussed below in conjunction with Table 38. 
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Record description 


Cjiernal formal 


Intern*! for 


m»l (bytes) 




Size 


Type 


Size 


Type 


Preferences Array 


8 


C 


8 


BIN 



Table 26: Exemplary preferences EF 716 file structure 



Rental Car Application 

Referring now to Figure 8, rental car application 4 1 4 preferably comprises 
JO common DF 802. directory EF 820. and one or more rcmal_car DFs 803 (i..e., 
803(8), 803(b), and so on) corresponding to individual rental car agencies. 

Common DF comprises preferences EF 805, which is described in detail 
below. Rental_car DFs 803 each comprise a rental_car Jd EF 807. reservation EF 
809. and expenses EF 8 n . 
1 5 Directory EF 820 includes a list of application identifiers and labels for the 

various DFs under rental_car application 414. The structure of this EF preferably 
conforms to that described above in the context of cardholder ID application 406. 

In a particularly preferred embodiment, preferences EF 805 comprises a set 
of preferences arm^ file structure as shown in Table 27 below. A preferred list of 
20 preference codes for use in each of these arrays is described below in conjunction 
vnihTable38. 
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Record decriptioii 


External formal 


Infernal for 


roat( bytes) 


Preferences Array (Dcfauli) 


8 


c 


8 


BIN 


Preferences Array (No. 2) 


8 


c 


8 


BIN 


Prefeftnce$Array(No.3) 


8 


c 


8 


BIN 


Prefenedlimousiitc compariy 


12 


AN 


12 


Asai 


Tabic 27: 


Exemplary preferences EF 
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Rcnia) car^id S07 is used lo store frequent rental information, upgrade 
information, insurance information, and the like. In a particularly prefened 
embodiment, rcnial_car_id 807 comprises a file suuciurc as shown in Table 28 
below. 



Record ilcscripiion 


Cxicrnal formal 


Ihiernal format( byies) 


tw^rttirnt Rental IDif 


22 


A 


22 


ASCII 


C OiffpOfiy name 


J 


A 


i 


ASCII 


Unitfve Customer JD 




A 


19 


Asai 


GDP (Contracf Disc. Program) 


10 


A 


10 


ASCII 


Accomulaicd points 


S 


N 


3 


BIN 


Renial fcaiurts 




AR 


2 


BIN 


Cor Type Upgrade 




B 


IbU 


D 


Week-^rtd/Vocotian Special 




D 


Ibit 


B 


Cuoronieed Late Reservation 




B 


I b it 


B 


Jnsunnce 




Atny 


7 


BIN 


Loss Damage Waiver (LDW) 




B 


1 bii 


B 


Personal Automobile Insurance 




B 


Ibit 


B 


Personal Effects Cmrrojie 




B 


1 hit 


B 


Personal Insurance 




B 


Ibit 


B 


Corporate Insurance 




B 


Ibit 


B 



Table 28: Exemplary rcnlal_car_id EF 



Reservation EF 809 is used to store confirmation numbers corresponding lo 
one or more rental car reservations. In a particularly preferred embodiment, 
reservation EJF 809 comprises a plurality of records (e.g., two) having a file 
structure as shown in Table 29 below. 



Record description 


ExiernsI formal 


Intern! formal bytes) 


Rental Car Company 


u 


3 


Asai 
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LocaMon 


3 


A 


3 


ASCII 




S 


D 


4 


BCD 


Time 


4 


T 


^ 


BCD 


Reservation Number 


15 


A 


15 


ASCII 


riishi. Number 


3 


M 


5 


BIN 


Airlines 


3 


Aff 


J 


ASCUffU) 


Fiighl nvmbcr 


4 




7 


BCD 


Preferred profile 


\ 


C 


1 


ASCII 



Tnbic 29: Exemplary reservation EF 
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Expenses EF 8 M is used lo record expenses incuned by ihe cardholder during 
car rcnial (e.g.. «he loial rental charge). In a paniciilarly preferred embodiment, 
expenses EF Sll comprises a plurality of records (e.g.. five) having a file structure 
as shown in Table 30 below. 



IS 



20 



Tabic 30: Exemplary expenses EF 



Record description 


EmrnBl rormst 


Inirrnal for 


m»t( byie$) 


Type of expense 


1 


C 


1 


ASCII 


Date 


8 


D 


4 


BCD . 


Locniion eodc 


3 


AN 


3 


ASCII 


Amount 


7 


N 


3 


BIN 
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Hotel Application 

Referring nowtoFigure9.hoiel system application412piefeiably comprises 

directory EF 920. common DF 914. one or more hotel chain DFs 902. and one or 
more property DFs 903. 

common DF 914 comprises reservation EF 918. expenses EF 916. key-of- 

the-room EF 910, and preferences EF 912. 
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Hold chain EFs 902(a), 902(b), and so on, comprise preferences EF 904 and 
stayer ID EF 906 associated with individual hotel chains. In contrast, property EFs 
903(a), 903(b), and so on, comprise a similar file slrxjciurc associated with 
individual hotel properties (i.e., independent of whether the panicular hotel is a 
member of a nationwide chain). 

In a panicularly preferred cmbodimcni, reservation EF 918 comprises a 
plurality of records having the structure shown in Tabic 31 below. In general, this 
EF is used to store confirmation numbers transmitted to smartcard 100 when the 
cardholder makes a reservation at a given hotel (designated in the properly code 
field). The date field stores the date on which the confirmation number was 
dispensed. 



Record dcscripiion 


Eyicrnal format 


Internal forma i(bytcs) 




Size 


Type 


Size 


Type 


Property Code 


3 


AN 


3 


ASCII 


Date 


S 


D 


4 


BCD 


Confirmation Number 


13 . 


AN 


IS 


ASCII 



Tabic 31 : Exemplary reservation EF 



Preferences EF 912 preferably comprises three sets of array preferences. The 
particular codes used in these arrays are discussed below in conjunction with Table 
38. 



Record description 


EYiernal format 


Internal format(bytC3) 




Size 


Type 


Size 


Type 


Preferences Array (dcfauh) 


« 


C 


8 


BIN 


PrefcfCDces Array (number 2) 


8 


C 


8 


BIN 


Ptrefcreflces Arr»y (number 3) 


8 


C 


8 


BIN 



Table 32: Exemplaiy preferences EF 
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Expenses EF 916 preferably comprises a lisi of reccni hotel expenses, for 
example, room costs, dinner expenses, and the like. In a particularly preferred 
cmbodimenl, expenses EF 916 comprises a plurality of records (for example, 
fifteen) arranged in a cyclic file siniciure and comprising the fields shown in Table 
33 below. Thus, the cardholder is able to examine and print a list of recently 
incurred expenses by type (a code fixed by convcnlion), date, amount, and property 
cckJc. 
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Record description 


External formal 


intcrnsi for 


msl(byics) 






Type 


S'tit 


Type 


Type 


1 


C 


I 


ASCII 


Dale 


S 


D 


4 


BCD 


Propcny Code 


3 


AN 


3 


ASCII 


Amount 


7 


N 


3 


BIN 



Table 33: Exemplary expenses EF 



Key-of-thc-room EF 910 preferably comprises clecuonic key values thai can 
be used in corjunciion with card readers to provide access lo particular hotel rooms. 
In a particularly preferred embodiment, kcy-of-ihe-room EF 910 comprises a 
plurality of alphanumeric key values as shown in Tabic 34 below. 



Record description 


ExiernsI format 


Iniernal for 


mat(l>ytcs) 




Size 


Type 


Size 


Type 


Key value 


40 


AN 


40 


BIN 



Table 34: Exeiuplaiy key-of-the-room EF 



Slayer ID EF 906 preferably comprises frequent stayer data for a particular 
hotel chain- In a particularly preferred embodiment. Stayer ID EF 906 comprises 
frequent stayer information as shown in Table 35 below. 
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Record dcscripiion 


External Tormat 


Internal 
format(bytcs) 




Size 


Type 


Size 


Type 


Frcqucni swycr number 


19 


AN 


19 


ASCII 


Ffcqucnt Siaycr Level Code 


1 


AN 


I 


ASCII 


Frequent Slayer Level Expiration Date 


6 


YYYYMM 


3 


BCD 


CDP 


10 


AN 


10 


ASCII 


Event Counter 


.3 


N 


1 


BIN 


Hotel Frequent Siaycr PIN 


8 


AN 


8 


BIN 



Tabic 35: Exemplary siaycr ID EF 



Preferences EF 904 preferably comprises three sets of array preferences as 
shown in Table 36. The particular codes used in these arrays arc discussed below 
in conjunction with Table 38. 



Record descriptloD 


External formst 


Inirrnal format(byics) 




Size 


Type 


Size 


Type 


Preferences Array (default) 


8 


C 


S 


BIN 


Preferences Array (number 2) 


S 


C 


S 


BIN 


Preferences Array (number 3) 


S 


C 


8 


BIN 



Table 36: Exemplary preferences EF 



Property DFs 903(aX 903(b)» etc., arc used in cases where the partnering hotel • 
is not part of a major chain, or when the hotel chooses to employ its own data set 
independent of its afiiliauon. In one embodiment, these properly DFs arc identical 
in structure to hotel chain DFs 902, except that much of the frequent stayer ID 
infomiation is removed. More specifically, a typical property DF 903 comprises a 
preferences EF 938 identical to preferences 904 described above, along .with a 
slayer ID EF 934 which includes only the CDP, event counter, and hotel frequent 
stayer PIN fields described in conjunction with Table 33 above. Altematively, a 
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particular hotel chain or propeny migh, choose .o implenKn. a different f.le 
structure than that desaibcd above. 



15 



Preference Codes 

„.entioned briefly above, a preferred embodiment is configured such .ha, 



5 are located in several files distributed throughout smartcard 1 00; i.e., 



AS 

904. and car preferences £F 8 ] 0. TOs ano^« apparently conflicting preferences 
coexist vnthin the caid depiending on 



to 



10 non-smoking in 



context. For example, it is possible to opt for 
,he cardholder ID application while choosing the smoking option 



within the hotel application. In the case 



of conflict, preferences arc read from the 



top 



level to the bottom level, and each level supersedes the p«v,ous 
An exemplary set of codification roles are 



one. 



set forth in Tabic 37 below: 



0-49 

50-99 

100-149 

150-199 

200-255 



General purpose (Cardholder ID 406) 

Hotel application 412 

Rental car application 4 1 4 

Airline application 410 

Other 
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. Tabic 37: Exemplary Preferences Code Ranges 

More specifcally. in a prefened exemplary embodiment, preference flags ate 
coded as set forth in Table 38 below. 





Code (dedmaO 


GENERAL PURPOSE 




Smoking ^ . 


00 


Non-$fnokin^ 


01 


Home as prcfcned address 


02 


Wofic as prcfcfred additss 


03 


Handicapped ^ . 


04 
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Home as preferred e-mail address 


05 


Work as preferred e-mai) address 


06 






HOTEL PREFERENCES 




Kin^size bed 


50 


Qucerv-size bed 


31 


Double bed 


52 


Hif h floor room 


53 


Lo^v Hoor room 


54 


Near elevator room 


55 


A^^'sy from elevator room 


56 






RE?^AL CAR PREFERENCES 




Compaa car 


100 


Standard car 


101 


Mid-size car 


102 


tuxurycar 


103 






AIRLINE PREFERENCES 




Window seal prcfencd 


150 


Aisle seal preferred 


151 


Low calorie 


152 


Vcseiarian 


153 


Diabetic 


154 


Low sodium 


155 


Kosher 


156 



Table 38: Exemplary preference codes 



Security 

.]n the context of smartcard transactions, data security has five primary 
dimensions: 1) data coniidentiality, 2) data integrity, 3) access control, 4) 
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a„,hcniicauon. and 5) non-rep»dia.ion. Each ofihcsc dimensions >s addressed 
through a variety of security mechanisms. Data confidentiality, which deals vith 
keeping ir^fonnation secret (i.e., unreadable to those without access to a key), is 
substantially ensured using encrjTtion technology. Data integrity (and data source 
verification) focuses on ensuring that data remains unchanged during tnnsfer, and 
typically employs message authentication techniques. Access control involves card 
holder verification and other requirements necessary in order for a party to read or 
update a panicular file. Authentication involves ensuring that the card and/or the 
external device is what it purporn to be, and non-repudiation deals with the related 
task of ensuring that the source of the data or message is authentic, i.e.. that a 
consumer may not repudiate a transaction by claiming that it was "signed" by an 

unauthorized parly. 

Authentication is preferably perfomied using a "challenge/response" 
algorithm. In general, authentication through a challenge/response system involves: 
Degeneration of a random number by z first party; 2) trananission of the random 
number to a second party (the "challenoc- 3) encryption of the rahdom number by 
the second party in accordance with a key known to both parties, 4) transmission 
of the encrypted random number to the first party (the "response"). 5) encryption 
of the random number by the first pany. and 6) comparison by the first party of the 
20 two resulting numbers. In the case where the two numbers match, authentication is 
successful: if not, the authentication is unsuccessful. Note that authentication can 
work both ways: the external world might request authentication of a smartcard 
(internal authentication), and a smancard might request authentication of the 
external world (external ao.hemica.ion). a more detailed account of a prefened 
challenge/response algorithm can be found in the IBM MFC specification. 

In a preferred embodiment, the DES algorithm (Data Encryption Standard) 
is employed for the various security functions; however, it will be appreciated that 
any number of other symmetrical or asymmeuical techniques may be used in the 
context of the present invention. More panicularly. there are two general categories 
of encrypuon algorithms: symmetric and asymmetric Symmetric algorithms use the 
same key for erKryption and decrypuon. for example, DBA (data encryption 
algorithm) v*ich t«es a 56-bit key to encypt 64-bit blocks of data. Asymmetric 
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algorithms, in conirasi, use iwo different keys: one secret key and one public key. 
The RSA algorithm, for example, uses two such keys and exploits the 
computational complcxiiy of factoring very large prime numbers. Additional 
information these and other cryptographic principles can be found in a number of 
standard texts, for example: Scberry & Pieprzyk, CRYPTOGRAPHY: AN 
Introduction to Computer Security (1989); Rhcc, Cryptography and 
Secure Communications (1994); Siinson, Cryptography: Theory and 
Practice ( J 995); Contemporary Cryptography: The Science of Information 
Integrity (1992); and Schneicr, applied Cryptography (2d cd. 1996), the 
contents of which are hereby incorporated by reference. 

Access control is suitably provided by including access conditions within the 
header of each EF and DF. This prevents a particular operation (e.g., reading or 
updating) from being performed on a file unless the required access conditions have 
been fulfilled. Many different access conditions are appropriate in a snwrt card 
context. For example, the smancard might require cardholder verification (i.e., 
request that the cardholder enter a PIN) before a file operation is allowed. Similarly, 
interna) and/or external authentication as described above might be required. 

Another imponant access condition (referred to herein as the SIGN condition) 
corresponds to the case where a panicular file is "protected" and where updating of 
a record requires "signing" of ihc data using a message authentication code (MAC), 
a MAC can be thought of as a form of electronic seal used to authenticate the 
conieni of the message. In a paradigmatic signing procedure, a shortened, encrypted 
representation of iJie message (the MAC) is created using a message authentication 
algorithm (M AA) in conjunction with a key knovw to both the card and external 
device. The MAC is then appended onto the message and scnl to the card (or 
external device, depending on context), and the card itself generates a MAC based 
on the received message and the known key. The card then compares the received 
MAC with the its own internally-generated MAC. If either the message or MAC 
was altered during transmission, or the sending pany did not use the correct key, 
then the two MACs will not match, and the access condition vnll not be fulfilled. 
If the two MACs correspond, then the access condition is fulfilled, and the 
particular file operation can proceed. 
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A MAC may be generaicd using a variety of MAAs, for example, the ANSI 
X9.9 method using an cighi-byie kcj-. oi the ANSJ X9. 1 9 method using a sixteen- 
byte key. Furthemiore. the actual key may be "diversified" through cncr>'ption with 
a random number or other appropriate value. These and Other details regarding 
MAC generation can be found in the references cited above as well as the IBM 
MFC spcdficatioD. 

7vrt> other iroponani access conditions are the NEVER and FREE conditions. 
The NEVER condition conesponds to the case ^where a certain file operation 
(typically updating) is never allowed. The FREE condiUon, on the other hand, 
corresponds to the case %vherc either updaUng or reading a file record is alvwiys 
allowed, without any additional preconditions for access. i 

In contrast to the MAC techniques discussed briefly above, non-repudiation 
is necessarily performed using asymmetrical techniques. That is. as symmetrical 
icchniques such as MAC "sealing" use a key known to more than one party, such 
techniques can not be used by a third party to ascertain whether the source of the 
message is correct. Thus, non-repudiation typically employs a public key encryption 
scheme (e.g.. the Zimmerman's PGP system), wherein the sender uses a secret key 
to "sign" the message, and the receiving pany uses the corresponding public key to 
authenticate the signature. In the context of the present invention, this function is 
suitably performed by allocating an EF for public and secret key rings, which are 
well known in the art. along wth suitable encryption software resident in the card 
for assembling ihc signed message. 

Having thtjs given a brief overview of typical smaiteard security procedures, 
an exemplary set of access conditions is set forth below in Table 40. In this regard. 
Ac various access conditions for each EF are tabulated with regard to whether the 
file is being read or updated. Jn each case, the access condition (FREE. SIGN. etc.). 
key "owner" Ossucr. panncr. user. etc.). and key name are listed. In this regard, it 
will be appreciated that the key name is arbitrary, and is listed here for the sake of 
completeness. 
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«F.ADINC 




UPDATING 






Access 
condition 


Owner 


Key 


Access 
condition 




Key 


MF 














DF Cardholder ID 406 














DFHoWcrjDSO? 














Ef ID504 


FREE 






SIGN 


ISSUER 


KEYI 


£F Home 506 


FREE 






SIGN 


ISSUER 


KEYI 


EF Business 508 


FREE 






SIGN 


ISSUER 


KEYI 


EF Preferences 5M 


FREE 








ICCI ICD 


KEYI 


EFPisspon5l6 


FREE 






SIGN 




t: PVi 


EF Diomcirics522 


FREE 






SIGN 


ICCI IITD 


i?nvi 

Kl^ Y 1 


EFDfivcf 5I» 


FREE 






SIGN 


ISSUER 


KEYI 


DF Misccllaneouj 














EFPaymcni card 510 


FREE 






SIGN ' 


■ COB IFCk 

ISSUER 


KtYl 


EF Sequence 512 


FREE 






FREE 






EF Card Number 526 ' 


FREE 






SIGN 




If PVI 

I^C T 1 


OF Payment System 408 














DF Issuer 602 














EFP»yI604 


FREE 






ro CP 






DF Airline 410 














DF Common 702 














EFPa5Scnfcr?06 


FREE 






SIGN 


ISSUER 


KEY2 


EF Ff <qucni flier 70S 


mEC 






SIGN 


ISSUER 


KEY2 


. EFIET7I0 


FREE 






FREE 






EF Board mg 712 


FREE 






FREE 






EFBiomcinc 714 


FREE 






FREE 






DF Issuer 704 














EFPiefcrences7I6 


FREE 






SIGN 


ISSUER 


KEY2 


EF PIN 718 


FREE 






SIGN 


ISSUER 


KEY2 


EFfasutnce720 


FREE 






SIGN 


ISSUER 


KEY2 


DFR£niaicar4l4 














DF Common 802 














EF Preferences 803 


FREE 






USER 


IDEKT 


PIN 


DF Rcnul e»r803 
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Tabic 40: Exemplary access conditions 

TrsDS^ciions 

Having Ausgivenadeuuleddescripnonofancxcmplaorsmancard 100 and 
ap^efened data stnKtorc 400. .he various details rda,cd,ouansa«ionsinvolv.„g 

3^,card 100 wi„ now be described. In general, a .ypica. s„«rtc,rd session 
invoNes- (D aclivatiOn of the contacts (or comparable non-contact means); (2) card 
(3) Answer to reset (ATR) by card; (4) Information exchange between card 
a„dl.s.;and.a.theconclusio„ofasession.(5)deactivationofcontacts. 

card ,00 is inserted in a card reader provided at an access pomt 15. artd 
^i^Weco— are made Ur^ communication region 104 oncard 100 and 

^ card reader. ,n a preferred embodimer.., physical contacts (contacts 106 m 
r«ur.l)«c«scd.andDATA.CLOCK.RESET.VDD.and<M)connectio«a« 
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made. ITiesc coniacts arc cicciricaljy aciivaicd in a particular sequence, preferably 
in accordance with ISO 78)6-3 (RST lo low stale. VDD powered, DATA to 
rcccpiion mode, ihen CLK applied). 

The card reader then iniiiaics a resci (i.e., RST lo high state), and the card 
returns an answer to reset siring (ATR) on the DATA line, preferably in 
conformance with the content and timing deiails specified in the appropriate pans 
of ISO 7816. In a preferred einbodimcni. the interface characters arc chosen to 
reflect a T=l protocol (asynchronous, half-duplex, block-oriented mode). Further 
in accordance with ISO-7816-3, after the card sends an ATR istring and the proper 
protocol is selected (in a preferred embodiment, the T=l mode), host 314 and card 
100 begin the exchange of commands and responses that comprise a particular 
iransnciion. The nature of these commands is discussed in further detail below. 

At the end of a smancard session, contacts 106 arc deactivated. Deactivation 
of contacts 106 is preferably performed in the order specified in ISO 7816-3 (i.e., 
RST to low Slate, CLK to low state, DATA to low slate, VDD to inactive state). As 
mcmioned above, the VPP contact is not utilized in a preferred embodiment. 

In the context of the present inveniion, command classes and instructions arc 
provided for 1) working with application data (i.e., files stored vnihin the various 
applications), 2) ensuring data security, 3) card management, and 4) performing 
miscellaneous functions. 

Application data commands arc suitably directed at selecting, reading, and 
updating individual records or groups of records within files. Security commands 
suitably include commands for performing ihc challenge/response authentication 
process, generating random numbers, loading or updating cryptographic keys, and 
changing and verifying the card-holder verification codes (CH VI and CHV2). Card 
management conunands suitably include commands which allow for the creation 
and deletion of directories (DFs) and elementary files (EFs). Miscellaneous 
commands are suitably provided for modifying the baud rate and reading various 
card statistics (e.g., data logged during production of the card.) It will be 
appreciated that many different command sets could be designed for implementing 
these basic functions. One such command set is provided by the IBM Multifunction 
Card Opaating System 3,5 1 , hereby incorporated by reference* 
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Referring asain «o Figure lO, access poiin 15 preferably comprises software 
which provides a user inicrfacc (for example, a graphical user interface) and is 
capable of executing the appropriate SCOS commands in accordance with the 
particular transaction being effected. For example, consider the case where a 
cardholder wishes to add a preference in car preferences EF 810 within rental car 
application 414 (shown in Figure 8). In this instance, a cardholder would locate a 
convenient access poim 15 (for example, a stand-alone kiosk in a mall) and insen 
card 100 in a provided card reader in order to initiate a transaction. After suitable 
handshaking between caid 100 and the card reader has taken place, and after the 
cardholder has been properly authenticated (i.e.. the correct access conditions for 
updating car preferences EF 810 have been fulfilled), the application program at 
access point 15 queries the leer with a choice of preference codes (for example, 
those listed in Tabic 39 above). The user then indicates a choice - through tcxwal 
or graphical means, and the appropriate value is sent to card 100 by the application 
15 program as pan ofa command string. This value may then be sent to the appropriate 

partnering organization 12 (i.e.. a remal car partner) and issuer 10 over network 1 9 
,o be stored in their respective databases 13 and 1 1. Alternatively, this data may be 
sent later as part of a card/database synchronization procedure. e.g.. When the 
original transaction proceeds off-line. 

Consider, as another example, the typical hotel transaction. As detailed above. 
,be cardholder inserts card 100 into a card reader deployed at a suitable access poim 
15. After appropriate initialization procedures take place, the cardholder is 
presented, through the use of a graphical user interface, the option to make a hotel 
reservation. Upon choosing this option, the software may interrogate the hotel 
preferences fidd inprefened programs EF 524 in cardholder ID application 406 and 

display these hotels first within the list of possible choices. 

After the cardholder selectsaspecifichotelproperty.thesofiv«iie contacts the 

appropriate paitnei 12 over network 19 and requests a hotel room for a particular 
set of dates. This step might invoJvfe ah interrogauon of the variot« files within 
hotel system application 412 lo which the particular hotel has access (i.e. a hotel 
chain DF 902 or property DF 903). or this step may be deferred until check-in (as 
described below). 
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Once a reservation has been made, ihe associated confirmation number 
supplied by the hotel is downloaded imo the confimialion number field in 
reservation EF 9lS along wjih the date and the property code of the hoiel. This step 
jnifiht require ihc cajdholdcr to iransmit appropriate credit card information, which 
is suitably retrieved from pay I EF 604. 

Upon anival at the hotel, the cardholder may use smaricard 1 00 to access a 
kiosk or other conveniem access point provided for check-in. Thus, check-in may 
take place unassisted by hotel personnel, or may involve a more traditional person- 
to-person interaction ^^re card 100 is used primarily to streamline the check-in 
process initiated by personnel at the front desk. 

At check-in, the confirmation number information is retrieved from 
reservation EF 91 S., and a particular room is assigned (if not assigned previously). 
This step will typically in\'olve retrieving, from the appropriate preference file (i.e., 
preferences EF 904 or 912). a list of preferences regarding bed size, room type, and 
the like. This list may be matched against the hotcPs database of available rooms, 
thereby helping lo streamline the room assignment process. * 

Once a room is assigned, a digital key conesponding to the assigned room 
(c.g-, a numeric value or alphanumeric string) may be stored in kcy-of-the-room EF 
910. Card readers are then employed as part of the door lock apparatus for each 
room, v^*jch arc configured to open only upon receiving the correct key. 

At check-out time, payment may take place using payment card information 
stored in payment card EF 3 1 0 and pay I EF 604. Again, a suitable smancard reader 
(i.e., an accesis point 15), may be provided in any location convenient for check out, 
e.g., the hotel lobby or within the individual hotel rooms themselves. The 
cardholder may then acquire frequent stayer points, which would involve updating 
one of the stayer 10 EFs 906 (or 936). During the course of his stay at the hotel, the 
cardholder may have incurred any number of expenses related lo room-scrvicc, on- 
site dining, film viewing, and the like. These expenses, or a subset thereof, may be 
conveniently do\vnloaded into expenses EF 916 for later retrieval, printout, or 
archiving. 

Use of card 100 in a rental car context would necessarily involve many of the 
same steps described above. The task of assigning a car would involve retrieving 
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car pi^fercnces siorcd within preferences EF 805 and comparing them to a database 
of available a.nomobilcs. Upon returning the automobile, the cardholder might then 
be a-'arded frequen. rental points (through update of frequent renter EF 807), and 
an expense record might be stored within expenses EF 811 . 

In ,he airline context, card 100 could be used to make reseivationi lecord 
preferences, and provide a payment means as described above. In additioiu 
electronic tickets may be downloaded (EF lET 7 1 0). and boarding information may 
be supplied via boarding EF 712. Frequent flyer EF 708 may then be used to update 
jhe cardholder's frequent flyer miles. 

While the example transactions set forth above are described in general temts, 
,he particular nature of data flow to and from the appropriate memory locations 
within the card will be apparent to those i -Jlled in the art. 

Moreover, although the inventions set forth herein have been desaibed in 
conjunction with the appended drawing figures, those skilled in the art will 
appreciate .hat the scope of the invention is no, so limited. For example, although 
.heprefened embodimem of the invention is discussed in the comext of a standard, 
credit card-sized smartcard with external contacts, it will be appreciated that 
virtually any portable memory device suitably configured may be utilized to 
practice this invention, for example, comacless cards, optical cards, minicards. 
••super-smart" cards, and the like. Hence, various modifications in the design and 
arrangement of the components and steps discussed herein may be made without 
departin- from the scope of the invemion as set forth in the appended claims. 
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CLAIMS: 
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1 . A smarlcard apparatus of the type configured to communicate with an external 
device to perform a transaction, said smartcard apparatus comprising: 
a smartcard body; 

an integrated circuit device disposed within said smartcard body and configured 
to communicate with said external device, said integrated circuit device including a 
cardholder ID application for storing infomation related to a cardholder's identity, and 
a payment system application, said payment system application including fields for 
storing indicia of at least one credit account associated with a partnering orgam'zation; 
and 

communication means for providing data communication between said 
integrated circuit device and said external device. 

2. The smartcard apparatus of claim 1 , wherein said integrated circuit device 
further comprises an airline application, said airiine application including a common 
airiine file and a second airiine file associated with a partnering organization. 

3. The smartcard apparatus of claim 1 , wherein said integrated circuit device 
further comprises a rental car application, said rental car application including a 
common car file and a second car file associated with a partnering organization. 

4. TTje smartcard apparatus of claim 2, wherein said integrated circuit device 
further comprises a hotel application, said hotel application including a common hotel 
file and a second hotel file associated with a partnering organization. 

5. A smartcard apparatus of the type configured to communicate with an external 
device to perform a transaction, said smartcard apparatus comprising: 

a anartcard body; 

an integrated circuit device disposed within said smartcard body, said integrated 
circuit device comprising: 



44 

(a) a cardholder identification application; 

(b) at least one second application for storing travel related information, said 
second application comprising a common file structure and at least one partner file 
structure; 

a communication means for providing data communication between said 
integrated circuit device and said external device. 

6. A smartcard apparatus in accordance v^th claim 5, wherein said conununication 
means comprises a plurality of external contacts disposed upon said smartcard body. 

7. A smartcard apparatus in accordance with claim 5, wherein said second 
application comprises: 

a payment system application; 
an airline application; 
a hotel application; or 
a rental car application. 

8. A smartcard apparatus of the type configured to communicate with an external 
device to perfonn a transaction, said smartcard apparatus comprising: 

a smartcard body; 

an integrated circuit device disposed within said smartcard body and configured 
to communicate with said external device, said integrated circuit device comprising a 
common application and a second application, said second application bemg configured 
to store travel-related information associated with a cardholder; and 

communication means for providing data communication between said 
integrated circuit device and said external device. 



9. The smartcard apparatus of claim 8, wherein said communication means 
comprises a phirality of external contacts disposed on a surface of said smartcard body. 
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10. The smartcard apparatus of claim 8, wherein said second application comprises a 
payment system application. 

1 1 . The smartcard apparatus of claim 10, w^ierein said payment system application 
is configured to store an account number and an expiry date associated with a payment 
account. 

12. The smartcard apparatus of claim S, wherein said second application comprises 
an airline application. 

1 3. The smartcard apparatus of claim 1 2, wherein said airline application is 
configured to store an electronic ticket. 

1 4. The smartcard apparatus of claim 8 ,wherein said second application comprises a 
hotel application. 

15. The smartcard apparatus of claim 14, wherein said hotel application is 
coniigured to store data associated with a hotel reservation. 

16. The smartcard apparatus of claim 8, w4ierein said second application comprises a 
rental car application. 

1 7. The smartcard apparatus of claim 1 6, wherein said rental car application is 
configured to store data associated with a car preference. 

1 8. The smartcard apparatus of claim 8, wherein said conunon application comimses 
an application configured to store indicia of said cardholder's identity. 

1 9. The smartcard apparatus of claim 1 8, wherein said indicia of said cardholder's 
identity includes a name and an address. . 
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20. The smartcard apparatus of claim 8. Mk^erein said common applicalion provides 
general read access. 



21. The smartcard apparatus of claim 8, wherein said second application comprises a 
common file structure and a partner file structure, wherein said partner file structure 
provides write access to a field within said partner file stnicture for a first partnering 
organization and denies write access to said field for a second partnering organization, 
and said common file structure provides write access for both said first and second 
partners to at least one field in said common file structure. 

22. A distributed transaction comprising: 

a networic for transmitting transaction information; 

a partnering organization having an Associated partnering organization server, 
said partnering organization server being configured to send and receive said transaction 
information over said network; 

a smartcard access point, said smartcard access point being configured to 
interface with a smartcard and to accept user input, wherein said access point is further 
configured to send and receive said transaction information over said network in 
re^nse to said user input, said smartcard comprising: 

a smartcard body; 

an integrated circuit device disposed within said smartcard body and configured 
to communicate with said smartcard access point, said integrated circuit device 
comprising a common application and a second application, said second application 
being configured to store travel-related information associated with a cardholder; and 
communication means for providing data communication between said integrated circuit 
device and said smartcard access point. 
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